Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/README_react.html:
- Around line 239-240: 説明文が逆転しており誤解を招くので、「左の左子が null だが右の右子はnull →
非対称」と書かれている箇所を修正して、鏡対応が崩れている具体例を明記してください：left.left が null である一方で right.right は 3
なので null と 3 が一致せず非対称になる、という文に置き換えて（left.left と right.right のミスマッチを明示する）。

In `@DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/Symmetric_Tree_Python.md:
- Around line 75-77: Update the assertion in the "A（再帰）" / "再帰版" paragraph that
claims "スタック問題もなし" to accurately reflect CPython's recursion limits: change the
text to note that while recursion is readable and typically fine for balanced
trees, degenerate (chain) trees can reach the CPython default recursion depth
(~1000) and raise RecursionError; reference the file's earlier notes (冒頭の説明 and
用語解説) and the iterative implementation docstring as corroborating context so the
statement no longer contradicts the rest of the document.

In `@DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/Symmetric_Tree_TypeScript.md:
- Around line 206-210: The trace for Example 2 incorrectly shows a comparison
pair as isMirror(null, null); update that line to reflect the actual comparison
isMirror(left.left, right.right) → specifically isMirror(null, 3) (or
equivalent) so the accompanying explanation about left.left = null vs
right.right = 3 matches the shown function call; locate the Example 2 trace and
replace the mistaken isMirror(null, null) entry while keeping the surrounding
lines and the isMirror symbol intact.
- Around line 224-235: Replace the O(n²)-causing queue.shift() usage by
implementing a head index or a proper FIFO structure: keep the existing queue
variable (const queue: Array<[TreeNode | null, TreeNode | null]>), replace each
queue.shift() call with reading queue[head] and incrementing head, and stop when
head >= queue.length so the loop becomes O(n); alternatively swap to a native
Queue/Deque implementation if available. Also correct the Example 2 trace where
isMirror(null, null) is shown — update that call and its inline annotation to
isMirror(null, 3) (and any related comment) so the trace accurately reflects the
pair (right-right child 3).

---

Outside diff comments:
In `@public/index.html`:
- Around line 419-822: public/index.html was edited directly but must be
auto-generated; revert manual changes and regenerate the file using the
generator script. Remove your direct edits to public/index.html, add any new
lesson files (e.g. new README_react.html) into the content tree, then run python
generate_index.py to produce an updated public/index.html (ensuring the lesson
count and footer date are updated by the script rather than manual edits).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/README_react.html:
- Around line 1863-1879: The useEffect currently resets activeStep to 1 and
stops playback as soon as the final step is reached (timer branch where
activeStep === stepsData.length), which prevents Play from actually starting
playback from the beginning; change the effect so it only stops at the final
step (call setIsPlaying(false)) without resetting activeStep, and move the reset
logic into handlePlay so that when handlePlay is invoked and activeStep ===
stepsData.length you first setActiveStep(1) then setIsPlaying(true) to start
playback; update both useEffect (referencing useEffect, timerRef, isPlaying,
activeStep, stepsData.length) and handlePlay (referencing handlePlay,
setActiveStep, setIsPlaying) in both the local file and the public JSX copy.
- Around line 1318-1334: Update the conflicting guidance text so the
recursion-safety threshold is consistent: replace the list item that currently
reads "ノード数が1000以内（デフォルトスタック上限内）" and the item that reads "深さ > 1000" with
wording that warns about recursion risk when tree depth approaches the
interpreter recursion limit (e.g., "深さが約1000前後になる退化した木（深さ ≈
スタック上限）では再帰が危険になるため反復版を検討する"), and apply the same replacement to the identical
paragraph elsewhere in the documentation so both occurrences of these phrases
remain synchronized.

In `@DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/Symmetric_Tree_TypeScript.md:
- Around line 339-342: Update the explanatory text to match the current
head-index implementation: replace discussion of queue.shift() with an
explanation that the code uses a head index (head and queue[head], then head++)
to achieve O(1) dequeues instead of O(n) shifts; mention the variables queue and
head and the expressions queue[head] and head++ as the mechanism ensuring O(1)
operations and why this preserves performance (avoids array reindexing done by
queue.shift()).
- Around line 96-100: Replace the environment-specific claim about Node's
default stack depth in the 方法A（再帰） rationale with a neutral, general statement:
remove the assertion that "Nodeのデフォルトスタック深度は通常10,000以上" and instead state that
recursion is more readable but can risk stack overflow on very deep trees, so
the iterative approach (方法B（反復）) is a safer alternative for extreme depths and
different runtimes (ブラウザ/LeetCode/Node) without citing Node-specific stack
values.

---

Duplicate comments:
In `@DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/Symmetric_Tree_Python.md:
- Around line 37-39:
「ノード数1000では問題なし」という一文が本文の他の注意（「最悪ケースでは再帰深度が上限付近に達し得る」）と矛盾しているため、該当箇所の表現をリワードして整合させてください；具体的には、現在の短評（"ノード数1000では問題なし"）を「再帰は可読性が高いが、退化した木（最悪ケース）では再帰深度がPythonの再帰制限に近づく可能性があるため、安全性を重視するなら反復版を推奨する」といった形に修正し、元の注意（"最悪ケースでは再帰深度が上限付近に達し得る"）と一貫するようにしてください（参照テキスト:
"ノード数1000では問題なし" と "最悪ケースでは再帰深度が上限付近に達し得る"）。

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@public/DataStructures/Trees/Other/101`. Symmetric Tree/claude sonnet 4.6
extended/README_react.html:
- Around line 1578-1589: The nodeColor function has a faulty condition that
highlights when key is 'L' or 'R' if either highlightLeft === 'L' OR
highlightRight === 'R', causing e.g. an 'R' node to be highlighted when only
highlightLeft === 'L'; fix the condition in nodeColor to require matching pairs:
check (key === 'L' && highlightLeft === 'L') || (key === 'R' && highlightRight
=== 'R') so each side only highlights when its corresponding highlight variable
matches the key; keep the later Set-based check for other custom keys
(highlightLeft/highlightRight) as-is.